Transaction aggregation engine

ABSTRACT

A database may be accessed to obtain data for a plurality of payment transactions. The plurality of payment transactions may be associated with at least one requestor and two or more providers. A first set of payment transactions are presented to the at least one requestor. The first set of payment transactions are selected from the plurality of payment transactions and aggregated based on having a first common provider selected from the two or more providers.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 10/805,414 filed Mar. 19, 2004, which claims the benefit ofU.S. Provisional Application Ser. No. 60/456,820, filed Mar. 21, 2003,all of which applications are incorporated herein by reference in theirentireties.

TECHNICAL FIELD

Exemplary embodiments of the present invention relate generally to thefield of commerce automation and, more specifically, to a method andsystem to facilitate payments transactions between users of a paymentsystem.

BACKGROUND

Network-based electronic marketplaces are becoming increasingly popularvenues for users (e.g., individuals, companies, and corporations) toperform purchase transactions whereby a seller agrees to transferownership of an item, or to perform a service, for an exchange of value.Very often, such a purchase transaction may impose payment obligationson one or more of the parties to a purchase transaction.

A number of network-based payment systems currently facilitate paymentsbetween users in satisfaction of such payment obligations. Where aparticular user has engaged in multiple purchase transactions, utilizingone or more transaction systems, making payments for these multipletransactions can be cumbersome.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of exampleand not limitation in the figures of the accompanying drawings, in whichlike references indicate similar elements and in which:

FIG. 1 is a block diagram illustrating a commerce system, according toan exemplary embodiment of the present invention, which includes atransaction system and a payment system.

FIG. 2 is a block diagram illustrating further details regarding anexemplary architecture for the payment system.

FIG. 3 provides an example of the exemplary fields that may be populatedwithin the payment table.

FIG. 4 is a flow chart illustrating a method, according to an exemplaryembodiment of the present invention, to retrieve transaction informationpertaining to multiple purchase transactions from a transaction system,such as the transaction system.

FIG. 5 is a flow chart illustrating a method, according to an exemplaryembodiment of the present invention, to present a plurality of purchasetransactions in an aggregation interface, in conjunction with a paymentoption to initiate an automatic payment process with respect to at leasta subset of the multiple purchase transactions.

FIG. 6 is an interface diagram illustrating an aggregation interface,according to an exemplary embodiment of the present invention.

FIG. 7 is an interface diagram illustrating a consolidation interface,according to an exemplary embodiment of the present invention, in whichtransactions having a common payee are grouped for the purposes ofpresenting the payer with the option of making a single payment to therelevant payee for multiple transactions.

FIG. 8 is an interface diagram illustrating a confirmation interface,according to one exemplary embodiment of the present invention, whichpresents details of a payment to be made by the user.

FIG. 9 shows a diagrammatic representation of a machine in the exemplaryform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

A method and system to facilitate payment in satisfaction of a paymentobligation imposed by a transaction are described. For some exampleembodiments, a payment system may include a transaction identificationsystem to identify a plurality of purchase transactions, establishedutilizing one or more transaction systems that impose a plurality ofcorresponding payment obligations on a particular user. An interfacegenerator generates an aggregation interface that presents the pluralityof purchase transactions to the first user. The plurality of purchasetransactions is presented in conjunction with a payment option toinitiate an automatic payment process with respect to at least a subsetof the purchase transactions. A payment engine initiates the automaticpayment process with respect to the first subset of plurality ofpurchase transactions upon election by the first user of the paymentoption. In the following description, for the purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific details.

FIG. 1 is a block diagram illustrating a commerce system 10, accordingto an exemplary embodiment of the present invention, which includes atransaction system 12 and a payment system 14. In the exemplary commercesystem 10, the transaction system 12 and the payment system 14 are shownto be distinct systems that communicate via a network 16 (e.g., theInternet, a Wide Area Network (WAN) or a Local Area Network (LAN)).However, in alternative embodiments, the transaction and payment systems12 and 14 may be more tightly integrated. For example, the paymentsystem 14 may be implemented as a sub-system of the transaction system12.

The transaction system 12 operates to facilitate the establishment oftransactions between users 20 that may access the transaction system 12via a network 18. The network 18 may be the same network as the network16 via which the systems 12 and 14 communicate, or may be a distinctnetwork. In any event, the transaction system 12 may facilitate theestablishment of any one of a number of transactions between users 20.For example, the transaction system 12 may function as a network-basedmarketplace via which a seller user 20 offers items or services forsale, and a buyer user 20 agrees to purchase such item or services. Thetransaction system 12 may also support any one of a number of pricesetting mechanisms, such as one or more auction price setting mechanismsor a fixed-price setting mechanism. The transaction system 12 may, forexample, operate as a person-to-person (P2P), a person-to-business(P2B), or a business-to-business (B2B) marketplace.

The payment system 14, in the exemplary embodiment, operates tofacilitate payments between users in satisfaction of payment obligationsimposed by transactions established utilizing the transaction system 12.The payment system 14 may be dedicated to facilitating payments withrespect to transactions established by one or more transaction systems12, or may be more widely deployed to facilitate payment fortransactions established in any manner. For example, the payment system14 may comprise the PAYPAL®, payment service operated by PayPal, Inc. asubsidiary of eBay Inc. of San Jose, Calif.

The payment system 14 is further shown to include a transactionidentification system 22, a payment engine 24 and a communicationssystem 26. The transaction identification system 22 is responsible, inthe exemplary embodiment, for identifying transactions establishedutilizing the transaction system 12, and for which a particular user, orgroup of users, have outstanding payment obligations. The payment engine24 is responsible for transferring funds (or other value) between usersand the communications system 26 is responsible for communicatinginformation (e.g., emails, markup language documents, instant messages,short message service (SMS), messages, etc.) to users. Such informationmay be information pertinent to services offered by, and activitiesperformed via, the payment system 14.

In one exemplary embodiment, the payment engine 24 may operate in themanner described in any of the International Patent Applications Nos.WO02069092, WO0205231, or WO0205224, each of which is incorporated byreference.

FIG. 2 is a block diagram illustrating further details regarding anexemplary architecture for the payment system 14. The transactionidentification system 22 is shown to include an Application ProgramInterface (API) module 30, a scrapper module 32 and a parser 34. The APImodule 30 issues calls to the APIs of transaction systems 12 to requestspecific information. The scrapper module 32, in one exemplaryembodiment, operates as an alternative to the API module 30 to retrievetransaction information from transaction systems 12 by “scrapping” suchinformation from web pages (e.g., HTML documents) in a manner well knownto those skilled in the art.

Both the API module 30 and the scrapper module 32 may communicatereceived, or retrieved, transaction information to a parser 34 thatparsers this transaction information to identify specific informationitems.

The transaction identification system 22 communicates transactioninformation to a database 36, in which are stored a payment table 38, apurchase transaction table 40, and a paid items table 42. The paymenttable 38 is populated with records generated by the payment engine 24,each record recording the transfer or receipt of funds into or from anaccount of a user. For example, for a single transaction where funds aretransferred from an account of a payer to the account of a payee, two(2) records may exist within the payment table 38, one record indicatingthe withdrawal of funds from the account of the payer, and anotherrecord indicating the deposit of the funds into an account of the payee.

FIG. 3 provides an example of the exemplary fields that may be populatedwithin the payment table 38.

The purchase transaction table 40 is populated primarily withinformation gleaned by the transaction identification system 22 from thetransaction system 12. Again, FIG. 3 provides a list of exemplary fieldsthat may be defined within the purchase transaction table 40.

The paid items table 42 is populated with records corresponding at leastpartially to records within the purchase transaction table 40, and forwhich corresponding payment records were located within the paymenttable 38, as will be described in further detail below. Specifically,upon identification of a correspondence, between a record in the paymenttable 38 and the purchase transaction table 40, indicating that apayment for a particular transaction had been made by a particular user,the record may be migrated from the purchase transaction table 40 to thepaid items table 42.

Returning to FIG. 2, the communications system 26 accesses an interfaceclass 44 that provides a range of functionality with respect to writingto, and reading from, the database 36. The communications system 26 isalso shown to include a webscript module 46 that, in one exemplaryembodiment, comprises a CGI BIN, which in turn includes a compare module48. The compare module 48 is responsible, in one exemplary embodiment,for detecting correlations or correspondences between records in thepayment table 38 and the purchase transaction table 40. In alternativeembodiments, the functionality included within the compare module 48 mayreside at other locations within the payment system 14, such as forexample, in an application executing on an application server (notshown) or as a script residing on a database server (not shown).

The webscript module 46 is responsible for retrieving information fromthe various tables within the database 36, and dynamically generatingfiles in the exemplary form of Hypertext Markup Language (HTML)documents, that include the retrieved information.

The communications system 26 may also include a number of servers (notshown) to facilitate communications with the payment system 14 over thenetwork 18. Such servers may include, for example, a web server, anemail server, an instant message (IM) server, a SMS server, etc.

FIG. 4 is a flow chart illustrating a method 50, according to anexemplary embodiment of the present invention, to retrieve transactioninformation pertaining to multiple purchase transactions from atransaction system, such as the transaction system 12.

The method 50 commences at operation 52 when a user 20 accesses thepayment system 14. The user 20 may login via a web interface provided bythe communications system 26 of the payment system 14, and be presentedwith a personalized interface displaying various options, services andpayment information relevant to the user 20.

At operation 54, the payment system 14 presents the user with a “findtransactions” option. In one exemplary embodiment, a “find transaction”button is presented on a web page generated and communicated from thepayment system 14 to a user 20. At operation 56, the payment system 14detects whether the user 20 has selected the “find transaction” optionby, for example, clicking on the “find transactions” button.

It will be appreciated that, in one embodiment where the payment system14 and the transaction system 12 are separate entities, the paymentsystem 14 will require access information from the user 20 in order toauthorize retrieval of appropriate information from the transactionsystem 12. In an alternative embodiment in which the payment system 14and the transaction system 12 are tightly integrated, the payment system14 may not require additional access information (e.g., a username/password) to access the transaction system 12, in which case theperformance of a number of the operations described below may beomitted.

Returning to FIG. 4, at decision operation 58, the payment system 14determines whether the relevant user 20 had previously provided, to thepayment system 14, user identifier and password information necessaryfor accessing information of the user 20 stored on the transactionsystem 12. Specifically, a user table 43, illustrated in FIG. 3, may bemaintained within the database 36 of the payment system 14, and thisuser table 43 may be accessed to determine whether a transaction systemuser identifier and password are stored for the relevant user.

In the event that a user identifier and password had not previously beenprovided, the payment system 14 then presents a registration page to theuser 20 at operation 60, and the payment system 14 receives the relevanttransaction system user identifier and password for the transactionsystem 12. The received user identifier and password may optionally thenbe stored in the user table 43 as part of a record for the relevant user20.

On the other hand, should it be determined at operation 58 that the useridentifier and password had in fact previously been provided, thisinformation is then retrieved from the user table 43 within the database36 at operation 64.

At operation 66, the payment system 14, and more specifically thetransaction identification system 22, provides the transaction systemuser identifier and password of the user 20 to the transaction system12. In one exemplary embodiment, this transaction system user identifierand password may be included within a call from the API module 30 of thetransaction identification system 22 to an API of the transaction system12. This call, in one embodiment, is a request to receive identifiersfor each transaction established via the transaction system 12 and inwhich the relevant user 20 was a participant or party. The call mayoptionally only request identifiers for transactions concluded within apredetermined time period (e.g., within the past 1 month, within thepast year, etc.).

At operation 68, the transaction identification system 22 of the paymentsystem 14 receives one or more transaction identifiers from thetransaction system 12 responsive to the request issued at operation 66.In the exemplary embodiment, the API of the transaction system 12 mayreturn a list of transaction identifiers to the payment system 14.

At operation 70, the payment system 14 then provides one or more of thereceived transaction identifiers back to the transaction system 23 aspart of a request for further information regarding the relevanttransactions. The transaction identifiers provided at operation 70 may,in one embodiment, be a subset of the identifiers received at operation68, this subset having been identified based on various criteria. Forexample, a compare module 48 at the payment system 14 may, prior tooperation 70, determine whether any of the received transactionidentifiers correspond to transaction identifiers recorded within thepayment table 38 for payments involving the user 20. Transactionidentifiers for which records exist within the payment table 38 wouldthen be excluded from the transaction identifiers communicated to thetransaction system 12 at operation 70. Again, the transactionidentifiers provided at operation 70 may, in one embodiment, be providedas part of a call issued from the API module 30 to an API of thetransaction system 12.

At operation 72, the transaction identification system 22 receivestransaction information, corresponding to the provided transactionidentifiers, from the transaction system 12. This information may beprovided as a response to the call issued from the API module 30. Atoperation 74, the payment system 14 writes the received transactioninformation into the purchase transaction table 40. Specifically, theAPI module 30 may provide the received transaction information to theparser 34, which identifies pertinent information within the retrievedinformation, and instructs a write operation to the purchase transactiontable 40.

In an alternative embodiment, the transaction information that isdescribed above as written at operation 74 that may be retrieved by thescrapper module 32, instead of or in conjunction with, the API module30. Specifically, the scrapper module 32 may communicate with thetransaction system 12 via a web interface (not shown) of the transactionsystem 12 to provide the transaction system user identifier and passwordof the user 20. In response to the provision of this information, thetransaction system 12 may generate web pages from which the scrappermodule 32, in conjunction with the parser 34, is able to extract thetransaction information that is then written to the purchase transactiontable 40 at operation 74.

It will be appreciated that the transaction information received atoperation 72 may pertain to transactions concluded by any one of anumber of price setting mechanisms. For example, where the transactionsystem 12 provides an auction mechanism, one or more transactions mayhave been established utilizing Dutch or Chinese auction formats.Further, the transaction may have been concluded utilizing a fixed pricemechanism. In any event, the transaction information received atoperation 72, and written to the purchase transaction table 40, mayinclude any information pertinent to a wide variety of transaction typesor price setting mechanisms. For example, where the transaction wasestablished utilizing a Dutch auction, the transaction information mayidentify multiple users, each having purchased a specific quantity of abatch of items that were offered for sell by a seller. In this case, asingle transaction identifier may be associated with multiple useridentifiers. A determination regarding whether a payment recorded in thepayment table 38 indicates a payment made by a particular user for apurchase transaction recorded in the purchase transaction table 40accordingly requires more than a comparison of merely a transactionidentifier, and will also require a comparison of transactionidentifiers.

Table 40 provides examples of transaction information items that may bereceived by the payment system 14 at operation 72.

FIG. 5 is a flow chart illustrating a method 80, according to anexemplary embodiment of the present invention, to present a plurality ofpurchase transactions in an aggregation interface, in conjunction with apayment option to initiate an automatic payment process with respect toat lest a subset of the multiple purchase transactions.

The method 80 commences at operation 82 with a comparison of records inthe payment table 38 with records in the purchase transaction table 40.This comparison is performed with a view to identifying purchasetransactions under which a user 20 has payment obligations, and forwhich no payment is recorded by payment system 14 as having been made insatisfaction of those obligations. This comparison may involve comparingany one or more of multiple fields within each of the payment table 38and the purchase transaction table 40. Furthermore, the comparisonoperation may, in certain embodiments, require that calculations ortransformations be performed in order to perform a meaningfulcomparison. It should also be noted that, in one embodiment, thecomparison operation also seeks to identify only transactions for whicha payment obligation is extant. Accordingly, at operation 82, a filteroperation may also be performed to identify such transactions. Forexample, where the transaction system 12 supports an auctionprice-setting mechanism, the transaction information received atoperation 72, described above with reference to FIG. 4, may identify anauction that has not closed and accordingly for which no paymentobligation yet exists.

In short, the operation 82 seeks to identify transactions for whichrecords exist within the transaction table 40 for which an unsatisfiedand extant payment obligation exists. This may involve applying multiplefilter criteria to filter out, for example, transactions for which apayment obligation has been discharged by the relevant user ortransactions for which the payment obligation has not yet matured.

As described above, for certain transaction formats or mechanisms, forexample, where items are being sold in a batch, multiple users may beassociated with a single purchase transaction. In this case, thecomparison operation 82 may involve detecting a correlation between bothtransaction identifiers, identifying specific transactions, as well asuser identifiers within the tables 38 and 40.

At operation 84, the payment system 14 creates records in the paid itemstable 42 for purchase transactions identified at operation 82 and forwhich the payment obligations have been discharged. In one embodiment,the comparison operation 82, prior to performing a comparison betweentables 38 and 40, may perform a comparison between entries of thepurchase transaction table 40 and the paid items table 42 with a view tofiltering transaction records for which a payment was previouslyidentified.

Operations 82 and 84 may, in one exemplary embodiment of thepresentation invention, be performed by the compare module 48 thatcomprises part of the communications system 26 of the payment system 14.However, in alternative embodiments, the operations 82 and 84 may beperformed by comparison logic that resides elsewhere within the paymentsystem 14, and that performs the relevant operation in response toevents other than a specific request from a user.

Return now specifically to FIG. 5, at operation 86, the webscript module46 creates a file or document, in the exemplary form of an HTML page,that includes transaction information for multiple purchase transactionidentified at operation 82 as having outstanding payment obligations,with respect to one or more users 20. Specifically, the HTML document isan example of an aggregate interface within which information regardingthe multiple purchase transactions is presented in aggregate view.Furthermore, the aggregate interface, together with transactioninformation pertaining to each of the multiple purchase transactions,presents a user-selectable payment option to initiate an automaticpayment process with respect to at least the relevant purchasetransaction.

FIG. 6 is an interface diagram illustrating an aggregation interface100, according to an exemplary embodiment of the present invention,which may be generated at operation 86. In the exemplary aggregationinterface 100, a table 102 presents an aggregate view of informationconcerning multiple purchase transactions. Auctions that were won by auser on the eBay electronic marketplace would be examples of suchtransactions. As shown, title, quantity, item number, winning bid, andclosing date information are displayed for each transaction. Inaddition, transaction information for each transaction is presented inthe aggregation interface 100 in conjunction with a payment option, inthe exemplary form of a pay button 104 and a removal option, in theexemplary form of a remove button 106. With respect to each of thetransactions listed in the table 102, a user 20 can elect to make apayment of an amount (e.g., the winning bid) by selection of the paybutton 104, or can elect to remove the transaction from a list ofpurchase transactions that the payment system 14 has identified ashaving outstanding payment obligations.

User selection of the pay button 104 will result in a communication tothe payment system 14 to initiate an automatic payment process withrespect to at least the pertinent transaction. Examples of suchautomatic processes may be any one of a number of payment flows,options, or processes offered by PayPal, Inc. One such automatic paymentprocess is a “Send Money” process whereby funds are transferred from anaccount of a buy user 20 that is maintained by the payment system 14 toan account of the seller user 20 also maintained within the paymentsystem 14. Each of these accounts maintained by the payment system 14may optionally be linked to financial accounts of the relevant usersmaintained with other institutions or systems.

As noted above, the table 102 only contains listings for transactionsthat the payment system 14 has identified as having correspondingoutstanding payment obligations. In an alternative embodiment, thepayment system 14 may include transactions for which there is apossibility that a payment obligation may arise at some future time. Forexample, if an auction is in process on which the relevant user isbidding, transaction details for that auction could be presented withinthe table 102. In this case, the relevant transaction details could bepresented in conjunction with an option for the user to elect automaticsatisfaction of a payment obligation in the event that the paymentobligation is incurred.

User selection of the remove button 106 will result in the relevanttransaction being identified by the payment system 14 as no longerhaving an outstanding payment obligation. In the exemplary embodiment,responsive to user selection of the remove button 106, a message iscommunicated to the payment system 14 that causes the payment system 14to initiate a process whereby a record for the pertinent transaction iscreated within the paid items table 42.

It will also be noted that the aggregation interface 100 includes an“add another account” button 108 by which the user can register afurther user identifier and password for accessing the transactionsystem 12. If such information has been previously be supplied to thepayment system 14, user selection of the button 108 will take the userto an interface that presents such further accounts for selection.

Returning to FIG. 5, at operation 88, the document generated atoperation 86 is communicated via the communications system 26 of thepayment system 14 to the user via the network 18. The aggregationinterface 100 is then presented to the user, for example, as an HTMLpage displayed by a browser client executing on a machine of the user20.

At operation 90, the payment system 14 receives user selection of apurchase transaction for which a payment is to be made, responsive towhich the payment system 14 initiates an automatic payment process.Specifically, at operation 92, the payment system 14 (e.g., using thetransaction identification system) determines whether any of themultiple transactions previously identified as having outstandingpayment obligations require payment to a common user or entity (orpayee). This determination is made by, for example, identifying recordswith outstanding payment obligations and reflecting a common seller useridentifier for the transaction system 12. A further determination mayoptionally be made to determine whether the payment obligations wereincurred in a common currency (e.g., the U.S. Dollar). If so, thetransactions reflecting a common payee are grouped and a furtherdocument in the exemplary form of a consolidation interface is generatedand communicated to the user 20 at operation 94.

FIG. 7 is an interface diagram illustrating a consolidation interface120, according to an exemplary embodiment of the present invention, inwhich transactions having a common payee are grouped for the purposes ofpresenting the payer with the option of making a single payment to therelevant payee for multiple transactions. Further, on the assumptionthat the payee may be shipping merchandise that is the subject of thetransaction as a single shipment, shipping insurance and winning bidinput fields 124, 126, and 128 are displayed. In one embodiment, thesefields may be automatically populated with information extracted fromthe transactions listed in the table 122. Alternatively, the payee hasthe option of entering an alternative shipping value, reflecting amodified shipping value that results from the bulk shipment of multipletransactions. For example, the listed shipping costs for each of thetransactions in the table 122 may be $3.00, assuming individualshipment. The cost of shipping the merchandise of all transactionswithin the table 122 together may however be less that the summed valueof individual shipping costs.

Within the consolidation interface 120, the user 20 is again presentedwith the option, by user selection of a remove button 130, to remove anitem. In one embodiment, user selection of the remove button 130 doesnot result in creation of a corresponding record within the paid itemstable 42, but merely operates to remove the relevant transaction from aconsolidated-consolidated grouping.

While the exemplary consolidation interface 120 is described as groupingtransactions in connection with a single common payee with which thepayer has transacted, in a further exemplary embodiment, consolidatedpayments to each of multiple payees, with whom the payer has transacted,may be facilitated via the consolidation interface 120. For example, theconsolidation interface 120 may present a grouped presentation oftransactions with payee A, with the option to make a single payment topayee A, and a grouped presentation of transactions with payee B, withthe option to make a single payment to payee B in satisfaction ofobligations. The concurrent presentation of consolidated transactionsfor each of multiple payees may also be presented in conjunction withshipping insurance and other related charges pertaining to theconsolidated transactions.

FIG. 7 also shows the consolidation interface 120 including a continuebutton 132, user selection of which results in display of a confirmationinterface.

FIG. 8 is an interface diagram illustrating a confirmation interface140, according to one exemplary embodiment of the present invention,which presents details of a payment to be made by the user 20. As willbe noted, the confirmation interface 140 is pre-populated withinformation identifying the common payer (e.g., the email address of thepayer), a payment amount, a shipping amount, a transaction total, andshipping information identifying an address to which the payer shouldship the relevant merchandise. It will be noted that the payment amountreflects a sum total of the payment obligations, whereas a shippingamount is somewhat less than a sum total of the shipping amounts for theindividual transaction for which a payment process has been aggregated.The confirmation interface 140 also illustrates a balance in an accountof the user 20 from which the payment is being funded. The confirmationinterface 140 is also shown to include a “send money” button 142 that isuser-selectable to initiate the automatic payment process whereby fundsare transferred from the payee to the payer. Returning to FIG. 5, atoperation 96, an automatic process is initiated for the selectedpurchase transactions.

In short, the above described exemplary embodiments of the presentinvention are advantageous in that the payment system 14 isautomatically enabled to identify transactions in which a particularuser has participated via one or more transaction systems 12, and thatmay or may not be affiliated with the payment system 14, to identifywhich of those transactions may have outstanding payment obligations,and to present each of the relevant transactions to a user for selectivedischarge of payment obligations. The exemplary embodiments arefurthermore advantageous in that the payment system 14 is enabled toidentify transactions with a common payer, and to aggregate andconsolidate the payment process with respect to that common payer formultiple transactions.

FIG. 9 shows a diagrammatic representation of a machine in the exemplaryform of a computer system 200 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a personal computer(PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant(PDA), a cellular telephone, a web appliance, a network router, switchor bridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The exemplary computer system 200 includes a processor 202 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 204 and a static memory 206, which communicate with eachother via a bus 208. The computer system 200 may further include a videodisplay unit 210 (e.g., a liquid crystal display (LCD) or a cathode raytube (CRT)). The computer system 200 also includes an alphanumeric inputdevice 212 (e.g., a keyboard), a user interface (UI) navigation device214 (e.g., a mouse), a disk drive unit 216, a signal generation device218 (e.g., a speaker) and a network interface device 220.

The disk drive unit 216 includes a machine-readable medium 222 on whichis stored one or more sets of instructions (e.g., software 224)embodying any one or more of the methodologies or functions describedherein. The software 224 may also reside, completely or at leastpartially, within the main memory 204 and/or within the processor 202during execution thereof by the computer system 200, the main memory 204and the processor 202 also constituting machine-readable media.

The software 224 may further be transmitted or received over a network226 via the network interface device 220.

While the machine-readable medium 222 is shown in an exemplaryembodiment to be a single medium, the term “machine-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” shall also be taken to include any medium thatis capable of storing or encoding a set of instructions for execution bythe machine and that cause the machine to perform any one or more of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, and optical and magnetic media.

Thus, a method and system to facilitate payment with respect to multipletransactions have been described. Although the present invention hasbeen described with reference to specific exemplary embodiments, it willbe evident that various modifications and changes may be made to theseembodiments without departing from the broader spirit and scope of theinvention. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

1. A payment system, comprising: a database to store data for aplurality of payment transactions, the plurality of payment transactionsassociated with at least one requestor and two or more providers; and atransaction aggregation engine configured to present, to the at leastone requestor, a first set of payment transactions that are selectedfrom the plurality of payment transactions and aggregated based onhaving a first common provider selected from the two or more providers.2. The payment system of claim 1, wherein a payment obligation for atleast one payment transaction of the first set of payment transactionsis outstanding.
 3. The payment system of claim 1, wherein the first setof payment transactions have a common payment currency requirement. 4.The payment system of claim 1, wherein the transaction aggregationengine is further configured to present, via the user device, a firstoption to select the first set of payment transactions from theplurality of payment transactions.
 5. The payment system of claim 1,wherein the transaction aggregation engine is further configured topresent, via the user device, a second option to automatically pay onlyfor the first set of payment transactions in a single payment.
 6. Thepayment system of claim 5, wherein the transaction aggregation engine isfurther configured to present, via the user device, a third option toremove at least one of the first set of payment transactions from thesingle payment.
 7. The payment system of claim 5, wherein the singlepayment comprises a transfer of a first amount from a first account to asecond account, the first account and the second account maintained bythe payment system.
 8. The payment system of claim 1, wherein thetransaction aggregation engine is further configured to set a secondamount as a shipping insurance for the first set of paymenttransactions.
 9. The payment system of claim 1, wherein the transactionaggregation engine is further configured to set a third amount as ashipping cost for items associated with the first set of paymenttransactions, the third amount being less than a summed value ofindividual shipping costs for each of the first set of paymenttransaction.
 10. The payment system of claim 1, wherein the transactionaggregation engine is further configured to display a second set ofpayment transactions aggregated as having a second common providerconcurrently with the first set of payment transactions.
 11. The paymentsystem of claim 1, wherein the plurality of payment transactions areestablished using a transaction system different from the paymentsystem.
 12. A computer-implemented method, comprising: accessing adatabase to obtain data for a plurality of payment transactions, theplurality of payment transactions associated with at least one requestorand two or more providers; and presenting, to the at least onerequestor, a first set of payment transactions that are selected fromthe plurality of payment transactions and aggregated based on having afirst common provider selected from the two or more providers.
 13. Thecomputer-implemented method of claim 12, wherein the presenting furthercomprises presenting, via the user device, a first option to select thefirst set of payment transactions from the plurality of paymenttransactions.
 14. The computer-implemented method of claim 12, whereinthe presenting further comprises presenting, via the user device, asecond option to automatically pay only for the first set of paymenttransactions in a single payment.
 15. The computer-implemented method ofclaim 14, wherein the presenting further comprises presenting, via theuser device, a third option to remove at least one of the first set ofpayment transactions from the single payment.
 16. Thecomputer-implemented method of claim 14, wherein the single paymentcomprises a transfer of a first amount from a first account to a secondaccount, the first account and the second account maintained by a samepayment system.
 17. The computer-implemented method of claim 12, whereinthe presenting further comprises setting a second amount as a shippinginsurance for the first set of payment transactions.
 18. Thecomputer-implemented method of claim 12, wherein the presenting furthercomprises setting a third amount as a shipping cost for items associatedwith the first set of payment transactions, the third amount being lessthan a summed value of individual shipping costs for each of the firstset of payment transaction.
 19. The computer-implemented method of claim12, wherein the presenting further comprises displaying a second set ofpayment transactions aggregated as having a second common providerconcurrently with the first set of payment transactions.
 20. Anon-transitory computer-readable storage medium storing instructionthat, when executed by a processor, cause the processor to: accessingmemory to obtain data for a plurality of payment transactions, theplurality of payment transactions associated with at least one requestorand two or more providers; and presenting, via a user device associatedwith the at least one requestor, a first set of payment transactionsaggregated as having a first common provider from the plurality ofpayment transactions.